The invention relates to installation of applications.
The OSGi Alliance is a standards organisation that defines a dynamic module framework for Java™. (Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.)
The unit of modularity defined by OSGi is an OSGi “bundle,” which is ajar archive containing OSGi metadata as additional headers in ajar manifest. The concept of an “application” comprised of multiple bundles is not standardized yet in OSGi, but technologies such as Spring dm Server and Apache Aries have defined an application as a collection of OSGi bundles (code modules). In order to reduce memory and CPU usage, multiple applications may run in a single OSGi framework instance. Such applications may specify dependencies on other bundles, packages or services.
The examples provided herein will be given with respect to package dependencies. This is for ease of explanation only and it should be appreciated that they apply equally to other kinds of dependencies such as bundles and services.
An application is intended to provide an isolation boundary such that the application internals cannot be seen from the outside. It is important, therefore, that applications within the same framework instance do not expose packages exported by their bundles to other applications unless the providing application chooses to export the package. For example, an application X contains bundle A and an application Y contains bundle B. Bundle A exports a package Q, whilst bundle B specifies an import for package Q. Package Q is not however intended to be used outside application X. Therefore, application X does not specify an export for that package. It is however necessary to provide additional support to prevent packages from being unintentionally shared across applications. Possible solutions and their drawbacks will be described subsequently.
An additional consideration is that applications may specify version level constraints. For example, application X may include a bundle A which imports package Q in the range 1.0 to 1.5. Bundle B, within the same application, exports package Q at version 1.2. However, application Y (running alongside X) contains a bundle C which exports package Q at version 1.3. In the absence of any application isolation, bundle A will typically use the most up to date version of package Q matching its import range and would therefore use the package from bundle C.
For application X to make use of application Y's package at version 1.3 may not however be desirable. Each application has been tested and quality assured using specific bundles and packages. Even though bundle A has specified a range that it supports, it may not have actually been tested for all versions within the range; rather there may be a long term plan to eventually test “A” with all versions within the supported range.
In a plain Java Virtual Machine (JVM), with a single global classpath, it is not possible to run multiple versions of the same Java class side by side. This is because the JVM will simply use the first version it finds on the classpath. OSGi enables this by having a distinct classpath and class loader for each bundle. Each bundle can then contain a different version of the same class and bundles can express a dependency on a specific package version (and therefore class version).
In less modular systems than one conforming to the OSGi standard, the opportunities to solve this type of problem are more limited. For example, it is known when downloading firmware levels onto communicating nodes that if a node already has a higher level of firmware than the level that is to be installed on that node, then the installation will not take place. Additionally, it is known in AIX® packaging for an install process to look for dependencies between patches being applied to AIX. If there is a conflict, then a sufficient number of patches are installed to enable the system to work. It is also known when installing IBM® WebSphere® Application Server applications onto a mixed-version cell (an administrative cell containing WebSphere Application Server nodes at different versions, that an application will be installed only onto those WebSphere Application Server nodes that support the requirements of that application (in other words, node(s) at the correct version). (IBM, WebSphere and AIX are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.)
The OSGi environment presents a different set of expectations which result in problems of their own.
Spring dm Server uses a single framework instance and relies on the system adding naming conventions to any bundle, package and service dependencies at runtime to isolate applications. This approach is not ideal since any user who knows the convention can easily gain access to the application internals.
The concept of nesting an OSGi framework within another framework is being standardized in the OSGi Alliance as a means for isolating internal middleware capabilities from applications (so applications do not have access to middleware internals).
Nested frameworks are also being seen as a possible mechanism for isolating applications from each other. Each application would be deployed into its own nested framework and therefore have its own package resolution scope. This solution is ideal from the perspective of providing application isolation but in cases where there are tens or hundreds of applications it has the potential to cause significant scalability issues. Additionally each framework instance has an associated cost (memory, CPU etc).